Software systems of sufficient scale are inherently complex. No single visual representation of a software system provides enough information to support reasoning about all aspects of the system. For this reason, a software architecture is described using a set of views that are often created to address the needs of specific system users and to support each in reasoning about their specific concerns. For example, a developer (or maintainer) of a software system might be interested in the organization of the code into modules. In contrast, a performance engineer might be more interested in how the system processes information, or how elements of the system are assigned to various hardware components.
Software visualizations, like software architecture views, are created to address the needs of specific, different users. In order to visualize a software system, one needs to first extract both the structure and relationship data from the development artifacts (source code). Even though many tools exist for this extraction, the information these tools tend to provide is voluminous and far too much to comprehend all at once. One purpose of software visualization, therefore, is to simplify the available information so as to convey enough information for the stated purpose without overwhelming the user with detail unrelated to the specified goals.
Design structure matrices (DSMs) have long been used for visualizing and reasoning about the structure and relationships of software systems at the highest levels, and are well-suited for providing concise, unambiguous answers to a specific set of questions related to the understanding and analysis of a software system's structure (i.e., code entities) and relationships (i.e., dependencies). A DSM is a square matrix where a code entity of a given system is placed as a header of a row of the matrix, and also placed as a header of a column of the matrix. In typical representations, the row and column order of each code entity is the same such that the DSM content is mirrored across the upper-left to lower-right diagonal line, where self-dependencies (e.g., “A” depending on “A”) appear along the diagonal of the matrix. Typically, the DSM is a binary matrix, where matrix cells contain either a 1 or a 0 (for example) to indicate a dependency of the code entity associated with the row on the code entity associated with the column.
In the context of the present invention, DSMs have been found to exhibit several properties that make them suitable for application to software systems analysis. Firstly, unlike graphical representations, the DSM representation scales and can describe and depict the inward and outward relationships between an extremely large set of code entities within the grid of the matrix. Additionally, DSMs are suitable for displaying hierarchical structural data and containment relationships—a close match to the file system structure within which developers logically organize the code entities into systems and subsystems, and the class hierarchy structure of object-oriented software systems.
DSMs are symmetric and, therefore, the order of elements along the axis can be changed without altering the representation semantics (as long as the same changes are made in the element ordering along each axis). For this purpose, as well as to aid in the analysis, algorithms have been developed to sort DSMs based on their dependency relationships (for example, from the highest to the lowest level of abstraction—in general, any specified ordering may be used). FIG. 1 illustrates a simple DSM, displaying a set of four elements A, B, C and D that have been sorted in this manner. Once sorted, violations in layering (dependency cycles) become directly visible as “above the diagonal” dependencies. That is, from the logic structure perspective, the existence of “above the diagonal” dependencies define a relationship from a lower level of abstraction upward to a high level, where this is counter to software engineering best practices. Referring to FIG. 1, the relationship between elements C and D is “above” the diagonal and should be evaluated. The remaining relationships shown in FIG. 1 are properly “downward”—from an element at a higher level of abstraction to an element at a lower level of abstraction.
Many tools currently exist for creating DSM visualizations of software systems from source code. Most of these tools allow a user to navigate through source code by collapsing and expanding successive levels of detail to move up and down through the file system or class hierarchy, allowing for the inspection of various code entity properties. One such tool is disclosed in U.S. Pat. No. 7,512,929, entitled “Apparatus and Method for Managing Design of a Software System Using Dependency Structure” and issued to N. Sangal et al. on Mar. 31, 2009. These various visualization tools are intended to provide complete contextual information about the displayed code entities (i.e., path and filename information), as well as detailed information about the number of inward and outward relationships and the existence of dependence between code entities—at least to the extent that the dependent entities are also directly present in the visualization.
It is this last point, however, that highlights the limitation in current DSM visualization techniques. Since the current DSM visualization techniques provide complete contextual information for its contents, and a user's screen size is finite, relationships to code entities not appearing in the visualization may not be displayed, or they may be displayed as aggregated relationship groupings at higher levels of abstraction. Similarly, structural entities are often displayed as higher level aggregations. As a result, only partial system information is displayed in the current DSM visualization techniques and as such it is only useful for inspecting and reasoning about the detailed relationships of a limited subset of the system's code entities at a time.
Thus, a need remains in the art for a way to utilize the DSM visualization technique that retains the detail required to fully define and analyze a specific software system, yet does not overwhelm the user (or the user's graphical capabilities) in the presentation of this detail.